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REMARKS 
STATUS OF CLAIMS 

All of original claims 15-18 and claims 19-33, added by amendment, are pending in the 
application. All then pending claims were rejected under several arguments in a non-final office 
action of 3/22/2002 and a final office action of 1/5/2004 relying on U.S. Pat. No. 5,710,887 
("Chelliah".) AppHcant responded to those arguments of rejection in responses filed 6/20/2003, 
10/24/2003 and 4/20/2004. After filing a Request for Continued Examination, the Office 
withdrew its previous rejections in an office action dated 1/3/2005, and rejected all of claims 15- 
18 and 19-33 under 35 U.S.C. §§ 102(e) and 103 relying on U.S. Pat. Publ. 2001/0011250 
("Paltenghe") and official notice. Applicant traversed all the claims rejections of that action in a 
response dated June 15, 2005. The Office in an office action mailed August 18, 2005 then 
withdrew the claims rejections based on the Paltenghe reference and offered new rejections under 
35 U.S.C. §§ 102(e) and 103 relying on U.S. Pat. 5,966,697 ("Fergerson".) 

APPEAL 

This response is accompanied by a Notice of Appeal and the required fee. Pursuant to the Pre- 
Appeal Brief Conference Pilot Program announced in the Official Gazette on July 12, 2005, this 
response is also accompanied by a Pre-Appeal Brief Request for Review and a statement of 
reasons. Claims 15-18 have been the subject of four rejections, and claims 19-33 have been the 
subject of three rejections, which is in excess of that required by 37 CFR 1.191. Applicants have 
now completely rebutted three sets of references put forward by the examiner in the pending 
claims, after requesting continued examination in the case. Applicants request every effort in 
disposing of this case with properly allowable claims. 
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ARGUMENTS 

Applicant now addresses each item of the latest office action, and has enumerated the arguments 
for convenient reference. 

1. Acknowledgment is made of the examiner's consideration of the applicant's prior arguments. 

2. 35 U.S.C. § 102(e) is cited in support of arguments of rejection made below. 

3. Claim 15 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 5,966,697 
("Fergerson"). It is alleged that Fergerson discloses all the steps recited by claim 15. 

Applicant traverses this rejection on grounds that at least steps A, B, D, E and F are not disclosed 
by Fergerson. As to step A, Fergerson does not disclose an E-Commerce portal, nor the use 
thereof. Rather, Fergerson uses a "main shopping program" written specially for the shopping 
activity (col. 9 line 15) that displays a list of merchants (col. 8 lines 1-4). A list displayed in the 
context of a custom program not accessible over a network is not a "portal." An example of an 
E-Commerce portal appears in figure 1 of the instant application, described on pages 10 to 12 
and in connection with the method shown in figure 2 and described on pages 16 to 20. 

As to step B, as Fergerson does not disclose an E-Commerce portal, it cannot disclose linking 
therefrom to a vendor commerce system. As to step E, as steps A, B and D are not disclosed, 
repetition of those steps is also not disclosed. 

As to step F, Fergerson does not disclose the segmenting and aggregation of product order items, 
nor does it disclose a plurality of back-end processing systems. The preferred operation of 
Fergerson is illustrated in figure 2, whereby a customer's entire selections are transferred from 
one merchant system to another, and the selections appear to be maintained separately for each 
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merchant. Furthermore, because a customer's entire selections are transferred from one merchant 
to another, there is no need to aggregate the selections. A reader of Fergerson would therefore 
not identify a need to segment and aggregate the items ordered for a particular vendor, as they are 
maintained separately in their own logical containers, hi the alternate embodiments described in 
col. 4 lines 49-57, col. 8 lines 32-34 and col. 9 lines 33-37 the storage of customer selections in 
memory is not disclosed to be different. 

As to step D, Fergerson does not disclose the transmission of a packet from a vendor commerce 
system to a common transaction processing system. As the system of Fergerson utilizes a custom 
software application, it could be implemented to transmit user selection data from the user's 
computer rather than a merchant computer. Fergerson does not say how selections arrive at a 
"checkout processor" in the alternative embodiment, and it is not inherent that selections or 
transaction packets would be transmitted from a vendor commerce system. Furthermore, by 
utilizing the transmission of transaction packets from the vendor commerce systems to a 
common vendor commerce system, a customer can visit several merchants at the same time and 
commit selections in any order, as opposed to the serial visiting/committing procedure disclosed 
by Fergerson. 

As to the examiner's particular allegations as to the contents of Fergerson, Figure 1 does not 
disclose an E-Commerce portal nor linking thereof, but rather a user computer, merchant 
computers and a checkout processor coupled by the hitemet. Figure 2 discloses a merchant's 
"product data", but does not disclose a local catalog of products, browsing for products, or 
selecting a product for purchase. Figure 3 discloses a method of shopping, but does not disclose 
the transmission of transaction packets, from a vendor commerce system to a common 
transaction processing system or other object. Col. 4 lines 49-57 discloses that "the user's 
selection data may be stored in ... [a] checkout processor", however Fergerson neglects to say 
how that selection data arrives at the checkout processor. Figure 2 does not depict the steps A-D, 
and indeed does not depict a repetition of any steps but rather a transference of data. The 
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discussion at col. 1 1 lines 27-35 does disclose a repetition of steps, but not of steps A-D. Figure 
8 does not explicitly nor inherently disclose the segmentation and aggregation of product order 
items by vendor. Col. 2 lines 55-57 lightly discloses a method of authorizing sales by credit card 
and transmitting receipts, but does not disclose the processing of product order items between a 
transaction processing system and a plurality of back-end processing systems. 

4. Claim 16 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 5,966,697 
("Fergerson"). It is alleged that Fergerson discloses all the steps recited by claims 15 and 16. 

Applicant traverses this rejection on grounds as stated for claim 15, and further that Fergerson 
does not disclose vendor-specific processing rules, customer-specific rules, nor the querying of 
databases containing those rules for processing a transaction processing system. Applicant 
repeats the arguments made in his last response: 

The meaning of processing rules and runtime payment logic are given in the 
specification: 

The local workflow and purchasing rules 50, 54 are generally specific to each vendor , 
and set forth particular rules that may affect how the specific commerce system deals 
with certain transactions. For example, a particular customer 42 may only be authorized 
to make a purchase of less than $5,000, and if the items stored in the local basket 52 
exceed this amount, then authorization from another individual is required. In this 
situation, the system can be programmed to send an email or other notification to the 
other individual to obtain authorization. Other, more complicated workflow and 
purchasing rules may be implemented within each vendor system. (Page 10, lines 10-17 
of specification.) 

Turning now to the specific transaction processing steps, at step 96, the ICC transaction 
processor 12 queries the merchant database 18 in order to obtain the merchant-specific 
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transaction processing rules. Each merchant (or vendor) can have their own specific rules 
setup for determining how their transactions are processed by the common back-end 
system 12. In this manner, although the ICC transaction processor 12 is common to all of 
the participating vendor commerce systems 34, 36, 38, each vendor commerce system 
can have a customized back-end processing scheme . Merchant-specific data processing 
rules stored in the merchant database 18 may include (1) merchant authentication 
information or a merchant account number; (2) preferred payment processor information, 
such as what payment verification ion system to use for transactions; (3) order 
fulfillment instructions; (4) accounting/billing instructions, and (5) other merchant- 
specific rules, including, optionally, certain merchant-specific runfime scripting 
algorithms. (Page 21, lines 3-13) 

After the ICC transacfion processor 12 has obtained the merchant-specific rules, at step 
98 it queries the customer database 58 in order to obtain any customer-specific 
transacfion processing rules . Although these customer-specific rules may take a variety 
of forms, in the preferred embodiment of the invenfion, these rules will generally include 
a customer account number (for verificafion purposes) and one or more runfime scripts 
for providing interactive feedback about the processed transactions to the customer's 
system 42. For example, the customer system 42 may be operating some type of 
enterprise system software coupled to a purchasing system for tracking purchased items. 
In this situation, a runtime script can be stored at the customer database 58 and processed 
by the ICC transaction processor 12 at the time that relevant transaction items are 
processed- In this manner, information regarding actual purchases that are committed by 
the system 10 can be transmitted back to the customer's system 42 in a format that is 
compatible with the customer's purchasing software system. Other types of runtime 
scripting algorithms could certainly be implemented between the ICC transaction 
processor 12 and the customer's system 42. (Page 22 line 9 to page 23 line 3.) 

At step 2, the payment proxy 16 executes the runtime payment logic 62 in order to 
determine how to process the particular transaction authorization request . The runtime 
payment logic 62 can take many forms and can operate many functions, in addition to 
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simply determining where to route the particular transaction request. For example, 
various business rules particular to a certain merchant could be executed bv the runtime 
payment logic . These business rules may take the form of scripting information that is 
stored in the associated merchant database 18. As described above, the merchant 
database 1 8 may include a variety of runtime scripts for instructing the E-Commerce 
system how to process the transactions for a particular merchant. It is the payment 
proxy's runtime payment logic 62 that executes these stored scripting commands to, for 
example, determine which payment verification system 22, 24 is operating most 
efficiently, or most inexpensively, etc., and then to route the transaction authorization 
based on the results of this determination. Many other real-time processing functions 
could also be implemented by the runtime payment logic 62, such as, for example, 
applying additional calculations to a particular order; interfacing information with an 
associated order fulfillment system; sending transaction alerts or other messages to an e- 
mail or pager system when certain products are purchased, certain price thresholds are 
exceeded, etc.; or to interface with other databases to either receive or update legacy 
data. (Page 25 line 15 to page 26 line 10.) 

From the above, it is clear that processing rules are instructions that permit custom 
treatment of merchants/vendors or customers, and provide for behavior in the transaction 
prescribed for or by particular merchants or customers. Rules are not mere information, 
such as account numbers and billing addresses, because rules define the functionality of 
the system with respect to the particular merchant or customer. Likewise runtime 
payment logic provides processing that determines how to process transaction requests 
for particular merchants and/or customers. 

Fergerson provides no rule-based custom treatment for merchants/vendors or customers. The 
examiner's reference to col. 8 lines 44-57 speaks only to product attributes. The reference to col. 
12 lines 55-67 speaks merely of the entry of customer billing data, such as an address and 
telephone number. That is not a rule. 
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5. Claim 17 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 5,966,697 
("Fergerson"). It is alleged that Fergerson discloses a system including (1) a payment proxy 
interface for communicating information to and from the transaction processor, (2) runtime 
payment logic for determining, in real-time, how to process a particular transaction request 
transmitted to the payment proxy from the transaction processor; and (3) a plurality of payment 
connection modules coupled to the runtime payment logic for interfacing the transaction request 
to one of a plurality of payment verification systems. (The arguments of rejection refer to claim 
16, as they did in the previous office action, but applicant will presume a reference to claim 17 
was intended as claim 16 does not recite these elements.) 

Applicant traverses this rejection on grounds that Fergerson does not disclose a payment proxy 
interface, runtime payment logic nor a plurality of payment connection modules as claimed. The 
absence of disclosure of rules and runtime payment logic was argued above and in the applicant's 
previous response. Applicant repeats the arguments made in his last response with respect to a 
payment proxy interface and system: 

The description of a payment proxy interface may be found generally between page 23 
line 19 and page 27 line 8 of the specification, a portion of which is reproduced here: 

FIG. 4 is a logical block diagram showing the preferred interaction between the ICC 
transaction processor 12 and the payment proxy system 16 shown in FIG. 1. The 
payment proxy system 16 provides a universal payment verification interface between 
the ICC transaction processor 12 and a plurality of payment verification systems 22, 24. 
Although described in the context of FIG. 1, the payment proxy system 16 can be used 
with a variety of different frameworks and different E-Commerce systems, and is not 
limited to the system shown in FIG. 1. 

Preferably, the payment proxy system 16 includes a front-end payment proxy interface 
module 60, runtime payment logic 16, and a plurality of payment connection modules 64. 
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As shown in FIG, 1, in the preferred framework, the payment proxy system 16 is also 
coupled to a merchant database 18 and a transaction capture database 20. The elements 
of the payment proxy system 16 are preferably implemented via software instructions 
stored within the payment proxy system 16, but could, alternatively be implemented in 
hardware or a mix of hardware and software instructions. The software instructions for 
carrying out the functionality of the payment proxy could be programmed using a variety 
of different programming techniques and using a variety of different programming 
languages as those of skill in this art will appreciate. 

The basic purpose of the payment proxy system 16 is to provide a universal payment 
verification interface between one or more transaction processing systems (or other E- 
Commerce systems) and a plurality of payment verification hosts. In this manner, 
flexible and efficient payment verification services can be provided to a plurality of E- 
Commerce systems, without any need for the E-Commerce systems to know the details 
of communicating with and effecting transactions with the payment verification systems. 
Such a universal E-Commerce payment verification interface is unknown in the prior art. 



Having determined how to process the particular transaction authorization request , the 
payment proxy 16, at step 3, then sends the transaction to the proper payment connection 
module 64. The payment connection modules 64 each provide interface programming for 
instructing the payment proxy 16 how to communicate with the plurality of payment 
verification systems 22, 24. At step 4, the transaction authorization is routed to the 
proper payment verification system. The payment processor then authenticates the 
transaction request at step 5 and transmits back to the payment proxy system 16 a failure 
code (indicating that the transaction was not authorized), or an "auth-code" (indicating 
that the transaction was authorized.) The payment proxy 16 then routes the code back to 
the ICC transaction processor 12 (or other E-Commerce system) at step 6, which, at step 
7, then reacts to the code by, for example, sending a message to the customer indicating 
whether the transaction has failed or has been authorized. 
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Using the specification as a guide, a payment proxy includes a universal payment 
verification interface between one or more transaction processing systems (or other E- 
Commerce systems) and a plurality of payment verification hosts, thereby presenting a 
universal transactional interface to E-Commerce systems. A payment proxy provides at 
least three functions: 1- receiving transaction authorization requests through a common 
interface, 2- routing transaction authorizations to the proper payment verification system, 
and 3- receiving and returning a failure code or an authorization code indicating failure or 
success. 

Fergerson makes no such disclosure, in Figure 8 or elsev^here. 

6. Claim 18 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 5,966,697 
("Fergerson") with allegations that Fergerson discloses all the limitations of that claim. 

Applicant traverses this rejection on the following grounds: 

First, Fergerson does not disclose a payment proxy system as argued in the response to the 
rejection of claim 17. 

Second, Fergerson does not disclose the use of a shopping basket local to a vendor commerce 
system and a global shopping basket located at a transaction processor. At most, Fergerson 
discloses a shopping basket containing selections from several vendors located at one of a 
merchant computer, a checkout processor or a vendor computer (col. 4 lines 49-57). 

Third, Fergerson does not disclose an E-Commerce portal, nor a system linked to an E- 
Commerce portal, as argued in the response to the rejection of claim 15. 
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7. Claim 19 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 5,966,697 
("Fergerson") with allegations that Fergerson discloses all the limitations of that claim. 

Applicant traverses this rejection on the grounds that Fergerson does not disclose a merchant 
database containing merchant-specific transaction processing rules, as argued in the response to 
the rejection of claim 16. Furthermore, Fergerson does not disclose a transaction processor in 
combination with a plurality of back-end processing systems. 

8. Claim 20 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 5,966,697 
("Fergerson") with allegations that Fergerson discloses all the limitations of claims 19 and 20. 

Applicant traverses this rejection on the grounds stated for claim 19 and further stated in 
response to the rejection of claim 15, that Fergerson does not disclose an E-Commerce portal nor 
any coupling thereto. 

9. Claim 21 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 5,966,697 
("Fergerson") with allegations that Fergerson discloses all the limitations of claims 19 and 21. 

Applicant traverses this rejection on grounds as stated for claim 19 and the further grounds stated 
in response to the rejection of claim 18, that Fergerson does not disclose the use of a shopping 
basket local to a vendor commerce system and a global shopping basket located at a transaction 
processor. 

10. Claim 22 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 
5,966,697 ("Fergerson") with allegations that Fergerson discloses all the limitations of claims 19, 
21 and 22. 
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Applicant traverses this rejection on the grounds stated for claims 19 and 21 and further for claim 
16 that Fergerson does not disclose rules of any kind, nor a customer directory stored at a vendor 
commerce system. 

11. Claim 23 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. No. 
5,966,697 ("Fergerson") with allegations that Fergerson discloses all the limitations of claims 19 
and 23. 

Applicant traverses this rejection on the grounds stated for claim 19 and further for step D of 
claim 15, that Fergerson does not disclose the transmission of a packet from a vendor commerce 
system to a common transaction processing system nor a transaction interface. 

12. Claim 24 is rejected under 35 U.S.C. § 103(a) as being anticipated by U.S. Pat. No. 
5,966,697 ("Fergerson") in view of U.S. Pat. No. 5,629,981 ("Nerlikar") with allegations that 
Fergerson discloses all the limitations of claims 19 and Nerlikar discloses the limitations recited 
in claim 23. 

Applicant points to the following instructions in the Manual of Patent Examining Procedure: 

'To establish a prima facie case of obviousness, three basic criteria must be met. First, there must 
be some suggestion or motivation , either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to combine 
reference teachings . Second, there must be a reasonable expectation of success . Finally, the prior 
art reference (or references when combined) must teach or suggest all the claim limitations ." 
MPEP 8th ed. 3rd rev. § 2142, page 2100-134 

Applicant traverses this rejection on the grounds that a prima facie case of obviousness has not 
been made, specifically that not all the combined references teach or suggest all the claim 
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limitations, that there is no motivation to combine Fergerson with Nerlikar, and further that there 
is no reasonable expectation of success. 

Applicant has argued above for claim 23 that the elements of that claim are not disclosed by 
Fergerson. Fergerson does not teach a packet containing an order header including customer 
authentication information in combination with order items or a time stamp. Rather, the 
reference at col. 5 lines 4-15 teaches the transference of selection data only (as exemplified in 
Table 1). As the alternative embodiment storing the selection data at the checkout processor is 
only briefly disclosed, Fergerson does not tell us whether the selection data is accompanied by 
other data in that embodiment. For example, if a network connection were maintained between 
the customer's computer and the checkout processor through the shopping activity, there would 
be no need to transmit customer authentication information in a packet. Fergerson therefore does 
not teach a transaction packet including customer and merchant authentication information in 
combination with order entry items, or a time stamp. The header disclosed in claim 31 of 
Nerlikar is not an order header, but rather a header containing a user identification number (see 
fig. 4 and corresponding disclosure.) A user identification number, as used in the Nerlikar 
system, confirms the identity of the person submitting the secure information to the second party. 
The order header according to claim 24 contains customer authentication information, which is 
not the same as user authentication information. For example, a customer might be a business or 
organization. Combining Fergerson with Nerlikar would result in a system usable only by 
individuals for themselves, and not by employees, associates, friends or family of a customer. In 
any event, Nerlikar does not teach merchant authentication information, nor does Fergerson. 

The motivation offered by the examiner fails to explain why one of ordinary skill in the art would 
think to combine Fergerson with Nerlikar; indeed the motivation confusingly points to "TCP-IP" 
without a reference, but not to Nerlikar. Although the TCP/IP protocol defines headers of a kind, 
it does not define a packet with an order header, nor customer or merchant authentication 
information, nor order entry items, nor does the TCP/IP protocol make such a suggestion. 
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Furthermore, the TCP/IP protocol is unencrypted and utilizes a datagram methodology,, and 
contrary to the examiner's statement would not result in providing transaction information in a 
secure manner due to the susceptibilities of interception and loss of datagrams across an Internet 
Protocol network. 

There is further no motivation to combine, nor a reasonable expectation of success in the 
combination of, Fergerson and Nerlikar. Fergerson teaches a shopping system. Nerlikar teaches 
a system of authenticating parties though the use of RFID tags or badges. Requiring any of the 
entities (customer, merchant or checkout processor) of Fergerson to obtain an RFK) badge would 
only encumber the shopping process by requiring the participating parties to secure physical 
RFED tags prior to the shopping activity, and would not result in a system that is more efficient or 
secure than that provided by a system that uses only credit card numbers. 

13. According to the Office Action Summary, claim 25 is rejected. The office action fails, 
however, to offer any grounds for rejection. Applicants traverse this rejection on grounds as 
stated for claim 19, and further that the Office has acted in violation of 35 U.S.C. § 132(a), which 
requires a statement of the reasons for this rejection. 

14. Claims 26-33 are rejected under 35 U.S.C. § 103(a) as being anticipated by U.S. Pat. No. 
5,966,697 ("Fergerson") in view of the collection of articles called "Clearcommerce." 

The collection of articles entitled "Clearcommerce" is a series of press releases of "Outreach 
Communications" (of which Julie Fergerson was president) and "ClearCommerce Corporation." 
As might be expected for press releases, the Clearcommerce articles contain almost no 
implementation-level information. The examiner's allegation that "the specifics of the proxy 
payment ... are highlighted in Clearcommerce ... teach the features of the instant claims" is 
grossly inadequate, particularly in light of the absence of any particular references to disclosure 
the claims limitations therein. Applicant can find no disclosure of the additional claims 
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limitations included in claims 26-33, and calls upon the examiner to meet his duty under 37 CFR 
1.104(c)(2) to provide the "pertinence of each reference, if it is not apparent, ... clearly 
explained." Namely, the limitations of claims 19 and 26 not recited by either reference include 
(1) a plurality of back-end processing systems, (2) a back-end processor interface for processing 
and routing stored transaction requests to the plurality of back-end systems, (3) merchant-specific 
processing rules, (4) a database storing those rules, and (5) a plurality of payment verification 
systems. 

As to claims 26 and 30, applicants traverse this rejection on the grounds stated for claim 19, 
further that Clearcommerce does not disclose the limitations of claim 19, and further that a 
plurality of payment verification systems are not disclosed by Fergerson or Clearcommerce. 

With regard to claims 27, 28 and 29, nether Fergerson (as argued for claim 17) nor 
Clearcommerce discloses a payment proxy system or a payment proxy interface. A checkout 
processor alone without the elements described above and in the specification is not a proxy 
payment system. 

As to claims 31 and 33 applicants traverse this rejection on the grounds stated for claim 19, 
further that nether Fergerson (as argued for claim 16) nor Clearcommerce disclose processing 
rules, customer or merchant specific, nor a database that stores such. 

As to claim 32, applicants traverse this rejection on the grounds stated for claim 19, further that 
nether Fergerson (as argued for claim 16) nor Clearcommerce disclose runtime scripting 
information. 

Furthermore, the office action fails to point out for claims 26 and 29-33 any reference disclosing 
the additional elements of those claims. Furthermore, the examiner's references to a "proxy 
payment processor" bear no clear relation to "a payment proxy system" and "a payment proxy 
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interface." Applicant therefore traverse this rejection for claims 26-33 on grounds that the Office 
has breached the obligation required by 35 U.S.C. § 132(a) of a statement of the reasons for this 
rejection. 

15. Requirement for a statement under 37 CFR 1.133. 

The Office sent an Interview Summary mailed 9/6/2005, which described the following contact 
with the Office: 

Everett D. Robinson called Examiner Fadok to request the correct patent number to the 
"Fergerson" reference incorrectly referred to on page 2 of the office action of 8/18/2005, shortly 
after that office action was received. The examiner did not answer, and Mr. Robinson presented 
the question to Examiner Fadok's voicemail. Examiner Fadok left Mr. Robinson a voicemail 
with the correct number of 5,966,697. No other information or issues were discussed. Other 
than the receipt of an Interview Summary including a corrected page 2, no further 
communication has been made between Examiner Fadok and Mr. Robinson to this date. 

The Interview Summary mailed 9/6/2005 includes a requirement for a written reply, referring to 
MPEP § 713.04. That section refers to 37 CFR 1. 133(b), which reads "In every instance where 
reconsideration is requested in view of an interview with an examiner, a complete written 
statement of the reasons presented at the interview as warranting favorable action must be filed 
by the applicant." The contact with Examiner Fadok was not an "interview." The contact did 
not involve a request for reconsideration, but rather a request for clarification of the grounds of 
rejection. For that, no statement is required by 37 CFR 1.133(b) to be filed, and applicant 
requests reconsideration of the requirement to file a statement under that section. 

This paper is intended to be fully responsive to the office actions of 8/18/2005 and 9/5/2005. 
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Respectfully submitted this day of November, 2005. 



Everett D. Robinson 
Reg. No. 50,911 

PARSONS, BEHLE & LATIIVIER 
201 South Main Street, Suite 1800 
P.O. Box 45898 
Salt Lake City, UT 84145-0898 
(801) 536-6724 
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